Government, business and such diverse industries as health care and power generation, which are responsible for operating with critical industrial, business, defense or personally identifiable information have an increased responsibility and liability to protect such data and transactions among people and, more recently, among robotic machines. The principle defense mechanisms are authentication techniques that mitigate threats from the proliferation of cyber-attacks, both malicious and non-malicious, which threaten the privacy of our citizenry and the protection of our critical infrastructure. Authentication, and enforcing the highest level of assurance for the accurate credentialing and identity of the persons and machine devices transacting on public and private networks, are, along with data confidentiality, the most important processes necessary to achieve cybersecurity.
A Level of Assurance (“LoA” or, alternatively, an assurance level “AL”) as used in this disclosure, describes the degree of confidence in the processes leading up to and including a transaction. It is defined by the framework of international standard ISO/IEC 29115, and U.S. government standard NIST SP 800-63, both of which are incorporated herein by reference. In short, a level of assurance provides assurance within a degree of probability, that the entity claiming a particular identity is the entity to which that identity was assigned. Proving someone is who they say they are or a process occurred as intended—especially remotely, via a digital service—is fraught with opportunities for an attacker to successfully impersonate someone, something, or a process.
The components of identity assurance are implementation specific, and as such it is recognized that a Level of Assurance is not a single number, but rather can vary depending upon the context. In the newly released NIST SP 800-63-3 guidelines, for example, there can be an assurance level for identity proofing (termed an “IAL” Identification Assurance Level”), for authentication process (termed an “AAL” Authentication Assurance Level), and for federation process (termed an “FAL” Federation Assurance Level). Consequently Assurance Level (or “AL”) is meant broadly to refer to assurance levels however denoted or calculated.
Whether dealing with military command and control, remote medical processes, or IoT machine-to-machine transactions, proper identification and credentialing of these entities uniquely enables the ability to achieve accurate, consistent, repeatable rule-based operations. Such vetted credentialing also reduces the liabilities from risks associated with the communications of information over network environments to specific destination devices without the dangers of hijacking or masquerading.
In security environments, authentication is generally provided by cryptographic functions, such as public key pairs and digital certificates, issued under the X.509 standards. X.509 is a standard that defines the format of public key certificates. An X.509 certificate contains a public key and an identity (a hostname, or an organization, i.e., federation, or an individual), and is either signed by a certificate authority or self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can rely on the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.
Cryptographic secret information, including private keys and the symmetric encryption key, are, for the highest levels of security protection assurance, created and stored within the boundary of a hardware security module (“HSM”) tested and certified for robustness by a national laboratory such as the U.S. National Institute of Standards and Technology under FIPS 140-2 Level 1, 2, 3 or 4. It is understood by those of ordinary skill in the art associated with this disclosure that an HSM differs from a trusted computing base, such as a Trusted Platform Module (“TPM”) conforming to specifications of the Trusted Computing Group in a least four respects: an HSM is hardware, while a TPM could be either hardware or software, a TPM contains no root of trust such as a certification from a validating authority, if the TPM carries an encryption key all usage of that key is outside the boundary of the TPM, and an HSM can have stored within its boundary an attestation key which is bound to the certificate and can be leveraged to carry a validated assurance level.
A metric for trustworthiness or a defined government and industry Level of Assurance measurement describes multiple identity authentication assurance levels for e-government transactions which can also be generally applied to other organizational or machine environments. An example of this is NIST Special Publication 800-63. It is obvious that specification of levels could change, but as an exemplar it is worth noting that each assurance level describes the degree of certainty that the user (or device) contains and makes available an identifier (a credential in this context) that describes their identity. In this context, assurance is defined as (1) the degree of confidence in the vetting process used to establish the identity of the individual (or device) to whom the credential was issued, and (2) the degree of confidence that the individual (or device) who uses the credential is the individual (or device) to whom the credential was issued. For example, in that schema, Level of Assurance LoA1 offers little or no confidence in the asserted identity's validity. Level of Assurance LoA2 offers some confidence in the asserted identity's validity. Level of Assurance LoA3 offers high confidence in the asserted identity's validity. Level of Assurance LoA4 offers very high confidence in the asserted identity's validity.
Example physical embodiments of an HSM for identification and confidentiality is a smart card registered to each user under personally witnessed oversight such as a face-to-face process used for a driver license or a Global Access card. In a government environment, this card has been named a Common Access Card “CAC”, or a Personal Identity Verification card “PIV”, or a similar descriptor, and has been qualified to provide the necessary security protection within its physical boundary. It generates authentication and digital signature key pairs on the card and encryption cryptographic key pairs within an extended hardware security boundary supervised by a credential provider, such as a trusted certificate authority. Typically the same credential provider signs the corresponding digital certificates. Under appropriate circumstances and consistent with applicable security policies, however, it is possible for a digital certificate to be signed by a second certificate authority. However accomplished, this binds the specific user to a specific card that contains cryptographic authentication information unique to that user as their credentials. The user is responsible for keeping their access password private and under their exclusive care.
Even with a secure escrow of the encryption private cryptographic key to a physically and electronically secure server, these critical cryptographic parameters belong specifically to the entity who owns the credential cryptographic module and therefore achieves a one-to-one unique and authentic association between cryptographic keys stored within the hardware security module, the hardware security module itself, and the entity.
The increased mobility of workers, consultants, warfighters or health care providers, however, requires that they have the means to maintain their mobile credentials, their cryptographic keys for authentication and security, when using devices such as smartphones and tablets. Given the ever-changing diversity, connectivity, and computing power of mobile devices, it is critical for the content of these devices to be provably identified and secured remotely, and the integrity of the data communications to be protected.
The form factor of a credit-card sized smart card device may not be compatible with or acceptable to interface with these target devices and may need to be replaced. A more versatile HSM might have various form factors and interfaces, for example MicroSD, compatible with tablets, smartphones, PC's and IoT controllers, either in embedded or peripheral embodiments, such as the Rosetta HSM manufactured by SPYRUS, Inc. of San Jose, Calif.
For millions of owners of credit-card sized smart card devices, located globally, exchanging their current smart cards for a different device (referred to herein as a “token”) by manual registration and face-to-face re-vetting of the owner it is not economically feasible. What is needed therefore is a method to create new cryptographic credentials remotely and securely for authentication, digital signature, encryption, and device identity that are derived from the original credentials, thereby maintaining the chain of trust for identifying and authenticating the owner, as well as a method to remotely and securely authenticate the original credentials. The new derived credentials must have the same Assurance Level as the original vetted credential. A successful transfer results in the new device having “derived credentials”.
There is, however, no current solution for derived credentials, nor for remote attestation of a security module's Level of Assurance, which would be useful for network connected IoT devices which are headless, e.g., have no means for a human interface, to be accurately identified and authenticated as to the Level of Assurance they can support for security protection while being used in critical applications.